Public key cryptography is implemented to exchange information with a basic level of security. Here's how public key works:
1. A first user generates a key pair, one public, one private.
2. The first user provides the public key to a second user and retains the private key.
3. The first user receives a message from the second user; the message is encrypted with the public key
4. The first user decrypts the message using the private key.
Digital certificates provide an extra level of security when used with keys. A digital certificate is a public key that has been digitally signed by a recognized authority (a Certificate Authority) attesting that the owner of the key is the actual owner. A Certificate Authority signs a user's public key with its own private key. Managing certificates uses the Public Key Infrastructure, or PKI.
Referring now to the drawings in general and to FIG. 1 in particular, a typical component provisioning flow using digital certificates is shown. The process begins when a Requester 110 creates a key pair and sends a certificate request 118, including the public key 115, to a Certificate Authority (CA) 150. Assume the Requester 110, for purposes of this disclosure, is a contract manufacturer who buys directly from a Trusted Platform Module (TPM) component manufacturer to the specifications of a system manufacturer (in this case acting as the CA 150).
The CA 150 decides whether to proceed. If the CA 150 is assured that the request is legitimate, the CA 150 forms and signs a certificate 155 and sends the certificate and the public key 115 back to the Requester 110. The Requester 110 then provisions the component 170 with the key 115 and certificate 155 and sends the provisioned component 175 to the final assembly point 190. Basically, component provisioning in the information technology (IT) environment follows these basic steps:
1. Generate a key pair;
2. Associate the key pair with the component;
3. Generate a certificate with the public key;
4. Provision the component with the certificate
The TPM 175 is an inexpensive crypto device that holds a key pair including a public key 115 that requires a certificate 155 issued by the system manufacturer acting as a (CA) 150. The system manufacturer is concerned that the contract manufacturer (the Requester 110) might ask for additional component certificates 155 and use the extra provisioned components 175 for counterfeit systems. In other words, the contract manufacturer acting as the Requester 110 is an untrusted source. When the Requester 110 is not fully trusted, the CA 150 cannot, with the information provided, definitively decide whether to issue the certificate 155.
This issue is worsened if the Requester 110 acts as the CA 150, because in that case, the Requester 110 can issue certificates 155 without detection. Another problem can occur when the system manufacturer acts as the CA 150. The system manufacturer can determine that extra certificates were issued but cannot undo the process in time to recover the incorrectly provisioned components. One solution might be for the system manufacturer to delay provisioning of the component 170 until final assembly. However, the certificate creation process might be slow and perhaps run over an unreliable link to a secure facility. Any delay would shut down final assembly.
There is a need for a system and method to overcome the above-stated shortcomings of the known art.